Fixing the issue of multiple actions calling the same method was (partially) fixed by syncing both the hashed method's description and the hashed original target's type description.

This only fixes the issue partially, as it will only work if the type we're syncing is a generic type and each possible action uses a different generic arguments. However, it should be enough to handle everything in the game, as well as most (if not all) mods.

As for fixing the issue where an action we sync is opening a confirmation dialog - the fix is a bit more complex.

I've added a new delegate that will work as a wrapper around the original action. It may return either null or the synced method as-is, in which case nothing will happen. However, the wrapper may return a different action that will be called instead of immediately syncing the method.

The wrapper is passed the current instance of the object, its arguments, the original `Action` that was going to be called, as well as the `Action` that, when invoked, will sync the data. The arguments are (currently) unused, but I've decided to include them for the case of future-proofing this code.

As for the wrappers I've included:

The wrapper for Caravan actions will return null (no wrapper) unless the method's declaring type is `CaravanArrivalActionUtility.<>c__DisplayClass0_1<T>`.

If the type matches then we will replace the original action with our own which will access the `action` field from the target type, and:
- If we're in a synced call, it'll execute that action.
- If not in a synced call it'll replace the action with our syncing action and call the original method, displaying the confirmation dialog (which, if accepted, will sync the call).

As for the wrapper for Transport Pods, it will return null (no wrapper) unless the method's declaring type is `TransportPodsArrivalActionUtility.<>c__DisplayClass0_0<T>`.

If the type matches then we will replace the original action with our own which will access the `uiConfirmationCallback` field.
- If executing commands, we set the confirmation to null and call the original method
  - This is done so the original method calls the actual action without the confirmation dialog
- If not executing commands and the field is null, just sync the call
- If not executing commands and the field is not null, call the confirmation callback with our syncing action as the action we pass to it

As an additional note, we access the inner compiler-generated types directly. This is due to `MpMethodUtil` not supporting generic types and methods. If we decide to make it support those, we'll need to change how we access those types.